Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000075_owner-urn-ietf _Tue Oct 22 18:31:49 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA16886 for urn-ietf-out; Tue, 22 Oct 1996 18:31:49 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA16876 for <[e-mail]>; Tue, 22 Oct 1996 18:31:45 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA11418  (mail destined for [e-mail]); Tue, 22 Oct 96 18:31:43 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA14246; Tue, 22 Oct 1996 16:31:34 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 Oct 1996 16:39:10 -0600
To: Larry Masinter <[e-mail]>, [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Larry Masinter (at least at 01:51 PM 10/22/96 PDT)
>Patrik Falstrom wrote:

>So I disagree with the assertion:
>
># For an ISBN, the followings should be equivalent:
>#   isbn:0-201-10174-2
>#   isbn:0201101742

I believe Patrik was saying that clients should *NOT* regard the
two as equivalent. The difference is whether some server, that
deals with ISBNs on a regular basis, may use a comparison algorithm
that is more accurate than the one clients have.

>which sounds like, but isn't the same as, what we wrote for the 'URN
>requirements' document in RFC 1737:
>
>>   o Simple comparison: A comparison algorithm for URNs is simple,
>>     local, and deterministic. That is, there is a single algorithm for
>>     comparing two URNs that does not require contacting any external
>>     server, is well specified and simple.

I think we all agree that clients need a simple algorithm, which will
probably be character-by-character comparison after we have removed
any %encoding, normalized any lexical equivalances (like the case of
the NID), etc. Patrik has raised one issue - should the "decomposition
rules in UNICODE [...] be part of these lexical equivalence
rules". I need to know more about those decomposition rules before I
can have an opinion on the subject, but it appears as if those
decomposition rules are going to be fixed across all namespaces.

As for the ISBN example above, decomposition rules or not, the
presence of hypens in one identifier and their absence in another
will cause the clients to say that the two identifiers are not the
same, although we happen to know they really do identify the same
resource. That's OK, the consequences of a false negative are much
milder than the conseqences of a false positive, so a simple comparison
procedure errs on the side of safety.

An issue that is open right now is if  we happen to be running a
server dealing with lots of ISBNs, are we allowed to run a better
equivalance algorithm that exploits our greater knowledge of the
ISBN namespace? Personally, I think that is a reasonable thing to
do. So, if such a server *somehow* gets two consecutive requests,
one for an ISBN with hypens and another for an ISBN without hyphens,
can it return the same resource or does it have to signal an error
in one of those cases? I think it should be able to return the resource
in either case, although there may be some way of indicating that
a particular form of ISBN is preferred in the future.

Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"